Hi
We currently have an app being rejected due to Guideline 5.4 (VPN apps). The answer from App Review was a vague reference to the app not providing enough information to the user about data collection.
About 6 months ago we added a modal sheet that requires agreement from the user before the app will attempt to create a VPN profile via NEVPNManager APIs. This was in response to a prior rejection, and our app was subsequently approved.
Following our latest rejected update we tried to clarify if our modal was being observed and after some back and forth, the latest rejection from Apple Review states that:
we still found that your app does not sufficiently explain how the app or VPN service is using data collected from users in the purpose string of VPN Configurations prompt.
I have scoured the documentation and gone through all the Plist options within Xcode and can find no reference to a custom purpose/privacy string on the VPN configurations prompt. My understanding is that the content of that alert is fully controlled by the system.
Has anyone else encountered this, or aware of any changes to the way VPN apps should create new connection profiles?
Many thanks
Post
Replies
Boosts
Views
Activity
Hi
Is anyone aware of a way to emulate the digital crown within the Vision Pro Simulator? I've tried various key/scrolling combinations without any luck.
I am interested to see how the progressive immersion mode works.
Thanks
I have just installed the latest Xcode (13.3.1) and am finding that when I attempt to build a kernel extension (which was compiling fine in 13.2.1) I encounter the following error:
error: use of undeclared identifier '__APPLE_CC__'
This appears to be inside an auto-generated file named
<TargetName>_info.c, located in ../Intermediates.noindex/<ProjectName>.build/Debug/<TargetName>.build/DerivedSources/
I couldn't see any reference to this change in the release notes for Xcode 13.3 or 13.3.1.
From some reading it appears that __APPLE_CC__ is related to a C compiler version.
Has anyone else encountered this or know whether this is a bug, or part of the deprecation of kernel extensions?
Many thanks
I have been in the process of porting a helper tool from communicating with a Kext for kauth to using EndpointSecurity directly. All was going well until I re-enabled SIP at which point I discovered a provisioning profile would be required.
As the helper tool is a plain executable this isn't possible but having read some forum posts regarding launchd daemons & Endpoint security I attempted to package the helper tool as an .app wrapper. This isn't working so far (SMJobBless fails), so I'm beginning to think this isn't going to work...
Any idea if this is achievable? Or am I going to have to re-work the ES logic in to a separate System Extension?
Thanks,
Adam