I am trying to develop an iOS 14 Widget in Simulator but each time I run the app I get the below warning.
MobileGestaltCache.c:38: No persisted cache on this platform.
This however breaks nothing but not sure how to fix this.
In my case, the full log reads
libMobileGestalt MobileGestaltCache.c:38: No persisted cache on this
platform.
The interesting thing is libMobileGestalt.
In this post, a lot of infos are given about it. It says e.g.:
/usr/lib/libMobileGestalt.dylib is a private Apple library describing
the capabilities of the iOS device, as well as some runtime
information: system version, build version, device type, current
status of the airplane mode, …
The implementation is similar to a
key-value database and the library exposes a simple function to
retrieve the value for a specified key:
id MGCopyAnswer(NSString
*inKey);
When calling this method with a key, it returns the associated value stored in the database, or nil if the key does not
exist.
I don’t know if one can read out this way interesting information, at least one shouldn’t, since the contents of this private database can change any time.
Obviously, this library writes also logs, and in this case some info about the device used.
One can surely ignore it.
Related
I hash my iOS executable at launch to verify its integrity, and have had no problems doing so until TestFlight -- which appears to modify the executable as well as install it in some funky (undocumented?) way.
Even more concerning is I get multiple hash values, which appear to vary by device or iOS version or carrier or something. I don't own enough devices to be certain. But none of the hashes match the one I compute prior to uploading to TestFlight.
So I have two questions: (1) What is TestFlight doing to my executable, and is the process documented somewhere? And (2) Does the final app store release pull the same shennanigan, or something similar, or does it leave my executable unmodified from when I uploaded it?
That's what code signing is for.
Code signing your app assures users that it is from a known source and
the app hasn’t been modified since it was last signed.
Source: https://developer.apple.com/support/code-signing/
It seems like Apple encrypts your app. While this post is about App Store submission, could be the same for Test Flight (not sure about this).
See: https://stackoverflow.com/a/5784332/2019384
Also it's not recommended to verify your apps integrity by yourself, as you'll run in such issues. Besides iOS already does this for you:
Apple does not provide any supported way for you to check your app’s
integrity. iOS already does that by default.
Source: https://forums.developer.apple.com/thread/52801
In addition to d4rk's answer, if you're using Swift, Apple compiles in appropriate bits to optimize your app for each device.
I want to make getting a new device as easy as possible in my iOS app.
However, I want to ensure that the old instance of the app (and more importantly the data) is no longer accessible on the old phone.
How can I track the uniqueness of a phone, and if the app has been installed on more than one device?
My goal isn't to control licensing, but rather to make sure the user knows what is "out there".
(My app stores private keys in the app container, and I want to ensure these keys don't fall into the wrong hands... hence the reason for my question)
UIDevice offers identifierForVendor
The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors, and for apps on different devices regardless of vendor.
Before Swift 2.2 the UUID value was the same every time I opened the app, now changes at every opening
I use this code:
UIDevice.currentDevice().identifierForVendor!.UUIDString
How can I do now to identify the user?
Every time you delete the app, the UUID may change.
If you just close and open the app, it's should be the same.
But if you delete the app (or install it again via xcode), it might change.
There are a couple of answers that explain why the UUID is resetting. There's one that offers a potential work around, but I'd consider it far from ideal. But I want to highlight something important about the way UUID's work that serves as a great workaround that has absolutely zero impact on the production OR debug version of your code base or compiled binary.
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them.
All you have to do to prevent this value from changing while developing App-A is to simply install App-B from the same vendor (yourself) and keep it installed during the life time of App-A's development. This is literally as simple as starting a blank new iOS project and install the blank slate to your test device (using the same developer account & such), and then never uninstall it again during development.
App-B keeps a constant UUID for the vendor (yourself) so no matter how many times you delete and reinstall App-A, it will always keep the same UUID.
This actually seems to be a bug IMO. Everytime I run my app in the simulator it generates a new Vendor ID. You can probably get round it by storing the ID into NSUserDefaults on the first bootup then retrieving / comparing the value from NSUserDefaults instead of getting it from identifierForVendor. This will save a static vendor id in defaults but in theory the vendor id will still be changing every boot up.
Kind Regards,
Krivvenz.
Update: I can confirm I have installed multiple apps on the same simulator too but the vendor ID is still changing on every boot.
Update 2: - I have logged this as a bug with Apple - 26195931.
The value of this property is the same for apps that come from the
same vendor running on the same device. A different value is returned
for apps on the same device that come from different vendors, and for
apps on different devices regardless of vendor.
The value in this property remains the same while the app (or another
app from the same vendor) is installed on the iOS device. The value
changes when the user deletes all of that vendor’s apps from the
device and subsequently reinstalls one or more of them. The value can
also change when installing test builds using Xcode or when installing
an app on a device using ad-hoc distribution. Therefore, if your app
stores the value of this property anywhere, you should gracefully
handle situations where the identifier changes.
Refer this link for more info.
In our applications the user autentications is based on the serial number.It seems that in ios 8 it is not possible to get the serialnumber.Is any other way?
Thanks in advance.
Apple deprecated access to a unique-per-device UUID (known as uniqueIdentifier as of iOS 6. As of iOS 7, they also blocked access to MAC querying the address, and other sorts of unique identifiers. Sometime between iOS 6 and today, they started rejecting any application that accesses this property.
There are two replacement APIs that might help: on UIDevice, there is identifierForVendor, that is consistent across your apps. And there is also an entire framework, AdSupport, who's job is to provide an identifier that can be used for advertising networks. This identifier has the limitation of people can change it whenever they want, so you cannot rely on it being consistent across multiple launches.
The hint Apple is trying to pass on here is "you cannot consistently, uniquely identify people per device across multiple apps that are not your own".
In addition to zadr excellent explanation I would like to not iCloud as another possible solution:
Simply store a value (as file or key-value) in iCloud. Only disadvantage of this approach is, that you will have to add the iCloud entitlement to your app if your app does not use iCloud yet. On the other hand there are some advantages
Very little / none additional effort necessary if your app already uses iCloud
No additional Frameworsk like AdSupport necessary
The saved value will be consistent between devices and app re-install
More than one app can share the ID by using the same iCloud (ubiquity container)
Of course in some cases this might be a little overdone but in other this can be a handy solution.
I would recommend using uniqueIdentifier as suggested above but saving in keychain. This way its reliably available to you all the time, and can be used to track the user.
I have a Blackberry app that stores an object in the persistent store. After updating the app, it is supposed to read the existing value from the persistent store, if any, and continue to use that value. This works on some devices, but does not work on others. I tested on several devices running OS version 7, all of which work as expected. However on a device using version 5 and another using version 6, the object is no longer readable in the persistent store.
This is the case even if I don't change anything about the app other than the version number. Same exact class/object being saved & loaded from the persistent store, and same object ID used to access it.
The process I'm following to reproduce this is:
Completely delete the app & all it's data using the command line.
Load a version of the app, by downloading a .jad file from a browser, verify that it stores data in the persistent store.
While the app is running in the background, load a later version via browser download of the .jad file.
After downloading the later version, the system asks if I want to replace the previous version, and I confirm that I do.
The system loads the new version, and prompts that I must reboot for the change to take effect. I select "Reboot".
Device reboots. The later version is running but cannot read the object from the persistent store.
A device on which I can consistently reproduce this issue is a Blackberry 9800 (Torch) running 6.0 Bundle 2647.
As mentioned above this only happens on some, not all, devices, which makes me think something other than a coding bug may be going on here.
Anyone have ideas about this issue or how to debug it further?
Peculiar case.
Are you sure the persistent storage is being committed? Something similar generally occurs for me when data has been stored in the storage but not committed. If that is the case, and you load the older version, store some data and reboot your device, the data will not be stored in persistence.
You mentioned that the app is still running in the background when you load a later version. You may want to check whether commit() gets executed or not.