I'm setting up an MDM installation to distribute apps to supervised devices and seem to regularly get the managed application into a weird state where it's "scheduled for management" but doesn't actually install to the device. It's unclear to me how it gets into that state or how to get it out of that state.
I tried to use the RemoveApplication command, but since it never actually installed, this failed to remove it. I was able to get it out of this state by turning the device off and letting it forget it's volatile memory and then turning it back on, but this is an unacceptable solution for the use case I'm trying to achieve. It also doesn't seem to always fix the issue.
I attempted to use a support ticket with Apple to resolve this, but they basically told me that the problem we're experiencing should be submitted as a bug report, so we submitted that to them.
Basically, I'm just wondering if anyone else has experienced this issue and if you have, do you know of any workarounds to get it out of this state?
Thanks!
Related
If this differs between versions of iOS or different types of state preservation, please say so.
In this case, I'm using application:shouldSaveApplicationState: and application:shouldRestoreApplicationState: – I'm not sure if state preservation/restoration is the correct term. (We're changing to application:shouldSaveSecureApplicationState: etc, but haven't released it yet.)
I'm asking because I'm looking into an error report that suggests that maybe a user got a bad state restored even after reinstalling the app, but I can't reproduce it, and I wasn't able to find docs that clearly stated what to expect if reinstalling.
It wouldn't be be logical for it to persist after app uninstall, so no, it does not.
Please note application:shouldSaveApplicationState: and application:shouldRestoreApplicationState: are deprecated since iOS 13.2.
EDIT: By uninstall I mean the user actively removed the app. I'm not talking about an app being off loaded by the iOS due to storage, at this case it is saved. The whole topic is extremely vague in the Apple documentation.
The answer is no, it does not.
We have an app that registers and runs a NetworkExtension (specifically NEPacketTunnelProvider) on both iOS and macOS. This works fine (although not in the iOS simulator, of course, known limitation). However, when the network extension is running, the App Store on macOS/iOS, and TestFlight on iOS, fail to update the app. It looks like they're waiting for the NetworkExtension to terminate, but not actually asking the VPN to disconnect.
We don't want our users to have to think about killing our VPN (which should stay connected whenever possible), but we don't want them to have to think about updates either - they should happen automatically.
Are we missing something? Is there an event we should be listening on to detect that the store is trying to install an app update? Conditions when we should arrange for the VPN to terminate, safe in the knowledge that it will be restarted again after being updated?
Apple had bugs regarding this issue. It was supposed to be ok since iOS 11 (and macOS 10.13 or 10.14), but then users reported that the problem still exists. Several bugs regarding this are still probably open at Apple's bugs reports, but we can't check their status.
You can ask again at their forum, and open another bug regarding this issue.
Probably there's nothing else you can do.
Those are only some of the reports related to this issue:
https://forums.developer.apple.com/message/174708#174708
https://forums.developer.apple.com/thread/92603
https://forums.developer.apple.com/thread/126471
https://forums.developer.apple.com/message/149563#149563
https://forums.developer.apple.com/message/183927#183927
Edit: Someone just posted a question regarding this at Apple's forum. It might be you who posted to question, but maybe it's someone else, so there's another reference:
https://forums.developer.apple.com/thread/128894
Okay, I have asked Reddit 3x and Apple once and no one could answer this so I am coming to you guys. Please be the ones to answer this validly. Okay, details. Yubo remembers my phone after reinstall and I do not know how. I have tried the following:
Changed my IP Address using a VPN
Change my IDFA through reset identifier which I now know is pointless as since I had “limit ad tracking” on the output would have been an output value of numerous 0’s (though this some how got me unbanned from the “Instagram” app, idk how tho)
Changed my IDFV by...well reinstalling the app (Yubo is there only app so don’t ask about other apps from the vendor)
Change my iPhones name multiple times
Prevented the app from being backed up on Icloud then reinstalling
I also logged out of the Icloud prior to using the app for the first time after reinstall
And that’s about it. I am aware the app may recognize: my phone, ios version and hardware. However, none of that is exclusive to my phone. I have read people having the exact same model and phone so i doubt Yubo is remembering me through that. I have never met an app so smart before, but I know some of you have probably been screaming this entire time one thing I have missed so please tell me what i missed and a way to change it without resetting my phone.
My device: Iphone6s and IOS 11
I went though lot of questions about tracking sms and call logs in non-jailbroken ios device. I came to conclusion that it is not possible.
But then I came across this
So I wonder how mspy does this. I am looking to built this functionality for enterprise app, so no problem of itunes rejection.
Can some one please help.
Thanks.
Please check these features description notes:
mSpy runs on jailbroken/non-jailbroken iOS devices. In the former
case, you need physical access for installation. In the latter case,
you need no access if you have iCloud credentials, but you get fewer
monitoring features. Still, the access may become necessary if iCloud
backup isn’t activated on the device.
I guess they are getting info from iCloud account but not the device itself. Moreover they have said fewer monitoring features , i dont know what they exactly mean by fewer and what info do they actually gets in that case. But they are sure getting info from already synced data over iCloud.
When contacted by a customer who is experiencing a problem in your iOS app and making an update to fix it, is there a way to get the user to verify the fix privately before making the update available to everyone?
Background: I was contacted by a user who is seeing a weird rendering problem since installing the latest update. Unfortunately I have not been able to reproduce the problem -- the customer uses an old iPhone model that I don't have access to, and I've had no luck reproducing it with the same iOS version in the simulator. However I made an update that I have good reasons to believe will fix it (I undid the small changes to the rendering code that were in the last update and did an alternative implementation that completely bypasses the issue, if my guess of what the issue is about is correct). But I obviously don't have 100% confidence that it will fix the bug since I can't repro it.
So I've submitted the update to iTunesConnect and have asked the user to wait until Apple has approved it. If it turns out that the change doesn't fix this issue, it would all be such a waste for the customer (who will have waited for nothing), for all my other users (who will see an update for nothing) and for Apple (who will have reviewed an update for nothing).
This is what ad-hoc deployment is for - testing. You can manually deploy a build to the customer (you need to know his devices UDID) or you can use a service like TestFlight (free) which helps to automate and manage the ad-hoc process.