I'm trying to save files generated while running unit tests that are later loaded through the same tests on a different simulator/at a different time. I can't use the NSDocumentsDirectory because it changes every time I run the app on the same simulator. What shared directory can I write to or what path can I write to where the files can be loaded between different test runs?
Notes:
The recorded data is being recorded as the tests run. I'm recording http traffic and writting it to files to be loaded later.
I'm running all the tests on the same simulator, so if the directory isn't accessible between simulators that's fine. I want it to be accessible by the same simulator on different runs.
When an iOS app writes to its documents directory on the iPhone simulator (NSDocumentDirectory), the data remains available to subsequent runs. Even if the app gets rebuilt/reinstalled, the data will remain with the app, but in the new NSDocumentDirectory. Even though the root app directory is different, the documents are automatically moved to the new NSDocumentDirectory.
So it just works, so long as its on the same simulator, in the same way it does if it is on the same device. You don't need to do anything.
I found that the trick when using the Mac OS X Finder or a terminal (for me) was to stop looking in the same absolute directory all the time, and get the app to log whatever the current documents directory is, and then check for the existence of the documents there in that new directory. I found that the system always moved documents there for me every time I rebuilt/reinstalled the app.
It appears to be much the same behaviour as when updating an app on a real device from the App Store, as far as I can tell. I guess it installs the new app, then moves all data from the old app to the new app, then deletes the old app.
Simulators are like separate devices: they can't share files, and neither can new installs (from a rebuild) of your app.1 I think you'll have to generate the files, and then find them manually in the simulated app container.
Then you can add the files to your test target in the "Copy bundle resources" build phase, then access them via NSBundle. The main bundle will still be the application even when testing, but you can find the right bundle with +bundleForClass: and a class that's only present in your test target.
1Son of a Beach's answer points out that this is wrong.
Related
I have developed a Flutter app that captures images using the camera and I store references to the image files using Shared Preferences.
When I upgrade the iOS app, the Shared Preference filename persists as expected, but the image no longer displays on the iOS device (and no longer seems to exist) File(_imageFileRef).existsSync() is false
For example, on iPhone, the image file is saved as
/private/var/mobile/Containers/Data/Application/580A9879-23CD-413D-A785-DB910673DF74/tmp/some_guid_image_name.jpg
When the app is upgraded, this file no longer seems to exist.
Where should I be saving the image files to in iOS so that they persist across upgrades?
The functionality works perfectly on Android devices.
Having received no answers, I delved a bit deeper and discovered that...
...the tmp directory in which the images are being written is for temporary files that do not need to persist between launches of your app. Your app should remove files from this directory when they are no longer needed; however, the system may purge this directory when your app is not running. The contents of this directory are not backed up by iTunes or iCloud.
So in order for the data to persist over app updates, I need to be writing to the Documents directory
Info obtained from here
I have an app that records and stores accelerometer data as core data managed objects. I would like to include some sample saved recordings in the simulator to test the app on different platforms, since the simulator cannot record from the accelerometer. I have successfully included *.xcappdata files in the build scheme and it works on devices, but simulator fetches come back empty.
Apple documentation seems to indicate that including app data in the simulator is possible but I have not gotten it to work. I have tested including data saved from one device on another device and that works fine. I am getting no error message, just an empty fetch.
I know I could include data in the form of text files in the app, read and format them upon launch, and save them as managed objects, but it would create a bunch of appendix code and files in the project, and I would rather work more cleanly.
You can find your application's data container path by running xcrun simctl get_app_container <device> <bundle identifier> data in a Terminal window. Device can be the name (quoted) or the UDID (see xcrun simctl list). For this to work, the relevant simulator will have to be running, and have a version of the app installed on it.
Right-click on the .appdata file to show the contents of package. Copy the core data files you got from Folders in AppData/* into the analogous directory then start your app in the Simulator.
Xcode does not currently have a GUI to manage containers in the Simulator like it does for physical devices. If you don't mind please file an enhancement request at https://bugreport.apple.com/ requesting this in the Devices & Simulators window.
I've just figured it out that, as a workaround at least for Xcode 9.2/iOS 11.2 simulator, you can set (HOME/CFFIXED_USER_HOME) (I'm not sure whether of those actually works) environment variables in launch arguments to a path to .xcappdata/AppData, like shown below (I used SRCROOT relative path just for illustration of possibilities - it works with any other kind of path like absolute ones and etc). Beware that the changes in the app data will be reflected right in that folder, so if you don't want that, it makes sense to point it to the copy.
I am working on a library with a very verbose logger module that, on iOS, writes xml logs to NSDocumentDirectory in a consistent file tree. I want to come up with a way for the user of this library to easily access these logs.
I know it is simple to programatically retrieve files from this directory, but is it possible to access this directory on an iOS physical device in any way from outside Xcode to retrieve these logs? I feel like I have seen it somewhere before, something in the manner of extracting the .ipa file and going into the package contents, but I could be wrong.
---------------------------------------------------------EDIT------------------------------------------------------------------
This (Browse the files created on a device by the IOS application I'm developing, on workstation?) is how to do it with Xcode on a device, but I have to assume that there is some way we can create that gets the logs off of a device for a user.
is it possible to access this directory on an iOS physical device in any way from outside Xcode to retrieve these logs?
It is possible to expose the Documents directory by enabling iTunes file sharing. When file sharing is enabled through this method, the contents of Documents directory would be visible to the user in iTunes, which can also be exported. The documents would also be visible for export through some third party desktop apps like iExplorer.
Here is the link to Apple documentation. You may also refer this thread to understand how this is done.
If you're using a simulator (apparently your task doesn't seem to need te real device) you are in luck.
You should go to a folder similar to this one:
/Users/[YOUR_USER_NAME]/Library/Developer/CoreSimulator/Devices/[RANDOM_HASH_YOU_SHOULD_DISCOVER]/data/Containers/Data/Application/[RANDOM_HASH_2_YOU_SHOULD_ALSO_DISCOVER]
Once there, with finder, you'll get the "documents" folder of the simulator and the app you're trying to retrieve your logs from.
You might say: I don't know which 2 RANDOM_HASHES should I go to.
Yes, you're right. If you have MANY simulators installed and or being used, it might be tricky to discover which one is the one you're trying to debug.
The same thing with your APP, your app will live in another RANDOM_HASH folder, and you should browse them, one by one, and then discover your documents folder.
Someone needed to solve this "mess" and created a Xcode Alcatraz Extension that leads you to the exact live simulator and APP you're debugging in any given moment, and then you don't need to guess which 2 random_hash paths you need to navigate to.
If Xcode + Alcartaz plugin extension manager is somewhat out of your reach, you might need to google it. It's not a difficult process.
PS: That magical Alcatraz Extension is named "XCodeWay" (in case you are brave enough to install Alcatraz onto your copy of XCode).
EDIT: Useful link to get Alcatraz: http://alcatraz.io/ Follow its easy instructions and you're done.
EDIT2: If Xcode cannot be used, then the last question in this other thread might come in handy: Browse the files created on a device by the IOS application I'm developing, on workstation?
(Still, an external application in your users machine will be needed )
We have created a new project with the same app ID, but this is designated a different folder in isolated storage. Why is this?
file:///Users/houman/Library/Developer/CoreSimulator/Devices/FBFFFF1E-B5C8-4541-AB4B-ED1657D43EB9/data/Containers/Data/Application/EB3A549F-1604-4E5C-8FBE-3076A3D581E5/Documents/
file:///Users/houman/Library/Developer/CoreSimulator/Devices/FBFFFF1E-B5C8-4541-AB4B-ED1657D43EB9/data/Containers/Data/Application/22E1E792-1F4F-4F05-B7D9-F61AD3624EE9/Documents/
Even though the apps share the same ID.
Since they don’t share the same location, no core data migration can take place.
Any advice please?
Update:
We have two apps in the AppStore and would like to combine the functionality. Hence the idea is to use the appID of the other app to push a new release from a separate project. We have the appID and right certificates, but the isolated storage seems to depend on something else than just appid. Without that a migration of existing data to the new system won't be possible. Alternatively we could copy and paste all files into the other project and go through lots of pain. That might make it possible.
I have seen this on my end - I believe (and could be wrong) that each simulator you run in gets its own folder on the disk. If you switch for iPhone 5 to iPhone 6s for example you may end up with a different folder.
I always actually (when running in the simulator) print out the on-disk location so that I can take a look at the sqlite file if i need to and recently (as of xcode7) i've noticed this directory change between runs - however in my case i tracked it down to changing simulator versions.
Mainly for security reasons. Every iOS application is placed in an application sandbox.
This not only refer to an application's sandbox directory in the file system, granting security by limiting the access to user data stored on the device, system services, and hardware.
I've been debugging a problem where my app successfully downloads a file and copies it to the Documents directory. Lately the app cannot open the downloaded file on subsequent launches of the app. I've been printing out file URLs and this is what I see when the file is initially downloaded and opened:
unzipped /var/mobile/Containers/Data/Application/9AC69C00-228E-482F-99D8-DD8F214FCE88/Documents/3.atcase to
/var/mobile/Containers/Data/Application/9AC69C00-228E-482F-99D8-DD8F214FCE88/Library/Application Support/thebundleID/current-case
You can see the UUIDs are the same, but when I launch the app again I see this:
couldn't unzip /var/mobile/Containers/Data/Application/9AC69C00-228E-482F-99D8-DD8F214FCE88/Documents/3.atcase to
/var/mobile/Containers/Data/Application/C18E7EFA-C0D0-4213-AF85-F5BC0D2A4207/Library/Application Support/thebundleID/current-case
This time the UUIDs appear to be different.
I will say tentatively that the answer is yes, the UUID used in the application container folder does seem to change every time the app is run, though I'd love to have some confirmation from a more experienced developer.
The solution to my problem was straightforward: Do not store absolute file URLs in the database. The URLs for the files are now constructed relative to the Documents directory URL every time the app is run. Since I name the files in a regular way, there is no need to store URLs anyway.