Open clem0338 opened 1 month ago
Hi I'm an AI powered bot that finds similar issues based off the issue title.
Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
SCDynamicStore is used by the runtime for NetworkChange (https://github.com/dotnet/runtime/blob/d38e5593427f63e513ca3be11c3fdccb07b88ce1/src/libraries/System.Net.NetworkInformation/src/System/Net/NetworkInformation/NetworkAddressChange.OSX.cs#L18) (https://github.com/dotnet/runtime/blob/bb63e362f4dce9db7caa70180ee3aef32cb36993/src/libraries/Common/src/Interop/OSX/Interop.SystemConfiguration.cs#L10)
(assuming that this file is also used for iOS as well).
I believe if you (or a library you are using) consume this function, then it will access SCDynamicStore and bring it in. Else, it would get linked out. This isn't an MAUI UI bug; it's more fundamental.
@rolfbjarne Is there anything they can do to diagnose which component is pulling in SCDynamicStore? Could this be a bug?
These functions are not private API, they're very much public:
So this looks like Apple updated their list of private APIs, and got it wrong (it wouldn't be the first time this has happened).
Typically publishing again works (because someone else complained and Apple fixed it), otherwise you'll have to escalate this to Apple (forums, support ticket, etc.)
@drasticactions: Upon examining the main assembly (out of the bin folder), there is no usage of the System.Net.NetworkInformation
namespace in our program or in the libraries used, only references to System.Net.Http
.
@rolfbjarne: I'm very surprised to be the only one using System.Net.Http.HttpClient on iOS, is there any (cross platform) alternatives ?
@rolfbjarne Is there anything they can do to diagnose which component is pulling in SCDynamicStore?
One rather crude way (but it could be effective), would be to:
Example:
$ dotnet build /p:RuntimeIdentifier=ios-arm64 /p:Configuration=Release
$ grep SCDynamicStoreCreate -R .
<hopefully interesting output>
There are a lot of intermediate build files in the bin and obj directories, and which files contain mentions of these functions may reveal which code references them.
Thanks for your advice, here is the result (of course I replaced the app name)
cedric@MacMini2020 ca7de8d236573ef8d3d4f42f9a3be06280d8c75ec51ec0927c59e6aaa93a5d31 % grep -lr _SCDynamicStoreCreate
./obj/Release/net8.0-ios/ios-arm64/ipa/Payload/[appname].app/[appname]
./obj/Release/net8.0-ios/ios-arm64/nativelibraries/[appname]
./obj/Release/net8.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Net.NetworkInformation.dll.llvm.o
./obj/Release/net8.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Net.NetworkInformation.dll.o
./obj/Release/net8.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Net.NetworkInformation.dll.s
./obj/Release/net8.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Net.NetworkInformation.dll.s.opt.bc
./obj/Release/net8.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Net.NetworkInformation.dll.s.bc
./bin/Release/net8.0-ios/ios-arm64/[appname].app.dSYM/Contents/Resources/Relocations/aarch64/[appname].yml
./bin/Release/net8.0-ios/ios-arm64/[appname].app.dSYM/Contents/Resources/DWARF/[appname]
./bin/Release/net8.0-ios/ios-arm64/[appname].app/[appname]
cedric@MacMini2020 ca7de8d236573ef8d3d4f42f9a3be06280d8c75ec51ec0927c59e6aaa93a5d31 %
OK, so the reference is clearly from System.Net.NetworkInformation.dll.
Note that you don't have to use this assembly yourself, any code you call may also call System.Net.NetworkInformation, which may make it rather difficult to remove.
As I said, my recommendation would be to contact Apple, because this clearly seems like an error on their side.
I have created a ticket on Apple Developer Forum, just waiting for it to be ... approved. Wait and see
@clem0338 can we close this issue?
@PureWeen: Here is the thread in Apple developer forum. I also sent a contact request with no response so far. I'd like this thread to stay open until further notice (or feedback from Apple).
IMO it should probably be moved to dotnet/runtime at least, since it's not a MAUI UI issue, but I do agree that it should stay open since it's related to the runtime, even if Apple needs to be the one to address it.
Thanks @jfversluis!
For those triaging this, this is not a dotnet bug directly but Apple's reviewers flagged APIs within the runtime that they said were private, but are not. This should stay open until we know from Apple that this is resolved, in case others trying to submit apps get hit by this.
I have exactly the same issue tonight
Just got this issue. The weird thing is that I submitted the same app yesterday and didn't add anything having to do with http. That was already in there yesterday. In fact I even have records in the server from this app that use http to post those records.
Hi all, I spoke to someone on the phone from Apple before finding this thread and they agreed that it was definitely a review issue and most likely not anything to do with .NET/MAUI, he said he was going to escalate it for me but the best bet was to email Apple Technical support from within the developer dashboard to get it to the right people.
Just ran into this too. Fun! Definitely new, was not having this a week or two ago.
Same here, was ok when pushed update to TestFlight yesterday, flagged as invalid binary today:
ITMS-90338
: Non-public API usage - The app references non-public symbols...:
_SCDynamicStoreCreate
, _SCDynamicStoreCreateRunLoopSource
, _SCDynamicStoreKeyCreateNetworkServiceEntity
, _SCDynamicStoreSetNotificationKeys
We have this issue as well. Apple just started to decline our TestFlight push since yesterday. The days before it was working just fine.
Just assembled a new build and encountered the same problem. Luckily, I managed to publish the main changes on Friday and can at least release them.
Same here. +1 for pushing the issue.
The same to me, the app can't be published in apple Store this morning. Yesterday it was working
Same here..
Same here, It was working yesterday
Relieved to discover this issue as just spent the last two hours trying to work out why an app that is identical to an app I submitted yesterday gets refused today. I had come to the same conclusion that it was a change that Apple made and broke submission of MAUI apps. This issue has now confirmed that for me. Hope it gets fixed soon!!!
Another one here being affected
Thank you all, it's nice not to feel alone anymore.
Apple: "Ups! I did it again!" +1 here with exactly same problem, at least my release is not priority, we will test with Android meanwhile.
Same Issue here..
Same here...
@rolfbjarne is there anything Microsoft can do to get Apple to fix this more quickly?
@rolfbjarne is there anything Microsoft can do to get Apple to fix this more quickly?
As far as I know Apple prioritizes based on number of customers affected. So if you all contact Apple (the more the better), then it's much more likely to get someone from Apple to take action asap.
I just filed a support case for it. We need to kick up the numbers on this one.
I just send a support request to apple as well.
Same issue here and have also escalated to Apple. Thanks for creating this thread, let's hope for a quick fix
@ore300 reported it's working now
Its now working for me too, I was able to push my app to the App Store.
Yes, it is working now.
Confirmed it is working for us too now. No response from Apple yet but it must have been escalated to engineering. Good result either way :)
Confirmed this is working now
also works for me. Whoever help in getting this fixed on Apple's side this is a L E G E N D!
Hi,
I just built and sent a new version, and ....
So it looks it still not working for me, maybe the fix only works in US ?
Edit: As you can see in the screenshot, I'm on UK Timezone
Hi,
I just built and sent a new version, and ....
So it looks it still not working for me, maybe the fix only works in US ?
Edit: As you can see in the screenshot, I'm on UK Timezone
All fine in UK
Hi,
I just built and sent a new version, and ....
So it looks it still not working for me, maybe the fix only works in US ?
Edit: As you can see in the screenshot, I'm on UK Timezone
I'm on IST time zone, but it is working for me now.
I'm desperate, I'm still not able to submit.
I sent two builds last Friday + 1 this morning + another one using VPN in case my "local Apple validation server" was the issue.
They are all rejected with the exact same message.
Apple did respond to me:
Hello Cédric,
Thank you for contacting App Review Support, my name is Orlando and I will be happy to assist you. I am following up with you regarding the status of your app.
Your app is in the “Ready for Distribution” status on the App Store as of February 27, 2024.
If you need further assistance, or if your app isn't visible on the store within 24 hours, please contact Apple Developer Program Support. Click “App Set Up and Distribution,” then click “App Store Search and Discoverability.”
If you have additional questions related to this request, please don't hesitate to reply to this email. I'll be happy to help.
Your case number is: [Case number].
Best regards,
Orlando
Apple Inc.
Then (after sending more details):
Hello Cédric,
My name is Bettina and I am with Apple Developer Support. I’m following up on your inquiry concerning the new version submission of your app “[App name]”
In reviewing your latest build delivery, we found an unexpected error in its processing. Details about the error should have been sent to you shortly after the delivery via automated email. Check your inbox and spam folders for this email.
If you're not able to locate the email, please add “no_reply@email.apple.com” as a valid email contact and attempt to redeliver the build with a higher build number. This typically resolves the issue.
If you do not receive the email detailing the error within 24 hours of submitting the new build, please respond with the following information:
App name
Apple ID of the app
Prerelease version and build number that is currently processing
A screenshot illustrating the current build or builds processing in the TestFlight section of App Store Connect
After we receive the requested information, we will investigate further and let you know when we have an update.
Explore developer resources to get answers to frequently asked questions, watch video tutorials, stay up to date with the latest news, and more.
Don't hesitate to follow-up if you have any further questions or concerns. I'm here to help.
For your convenience, the case number for this correspondence is [Case number].
Best regards,
Bettina
Apple Inc.
It means they did not even take a loot at this thread, the one on Apple forum, and - this is the most disturbing - to the details I sent in my contact request. This is totally pointless
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
Description
Hi,
we were able to migrate our solution from Xamarin to MAUI (.net 8).
After a 2 weeks fight, the app is finally working on Android and iOS in both Debug and Release configuration.
Unfortunately, after sending to Apple, the app is rejected because of the following:
From what I understand, this is because the 4 methods (_SCDynamicStoreCreate, _SCDynamicStoreCreateRunLoopSource, _SCDynamicStoreKeyCreateNetworkServiceEntity, _SCDynamicStoreSetNotificationKeys) exists in the generated Mach-O binary.
Those methods are not used directly by our application but because of HttpClient we are using to request our business API The methods are implemented in the System.Net.NetworkInformation assembly which is referenced in the System.Net.Http assembly
Steps to Reproduce
No response
Link to public reproduction project repository
No response
Version with bug
8.0.40 SR5
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
iOS
Affected platform versions
Targeted iOS version: 11.0
Did you find any workaround?
No workaround found
Relevant log output