It's really easy to retrieve main bundle's path for an app:
let path = NSBundle.mainBundle().bundlePath;
On a device running iOS 9, the result maybe something like:
/var/containers/Bundle/Application/52E76B99-BF75-4E99-82BB-51307695E694/AppName.app
The result shows that application installed via Xcode is stored under /var/containers/Bundle/Application on iOS 9.
But in some other devices, the main bundle's path is something like:
/private/var/mobile/Containers/Bundle/Application/0E6DD32F-4E6F-4E54-B47E-A91060097E16/myapp.app
That's weird. That two paths differ a lot. I wonder what may produce that differences?
You should never use the path if you're storing it for later use or comparison. As it will always change and generated run time by iOS but its iOS responsibility to get you the right path when you ask for the bundle path. So you should always use a path which is created run time.
Good to read.
Related
In the iOS variant of my Flutter app, when I explicitly create a .jpg file using
File(path.join(filePath, fileName))
..createSync(recursive: true)
..writeAsBytesSync(buffer);
the widget that renders the file (by calling Image.file(), passing to it the file as an argument) results with a blank image.
No exception was thrown indicating that the file was not found or file contents was invalid. Its behaving as if the file is blank, but when I browse to the file using Finder, the file is there and when I click on the image, Preview renders the expected image.
When the same code is executed when the image comes from the device camera or device gallery, it works and when the same code is executed in the Android variant with the file being explicitly created, it works too.
The only thing I can think of is that it has to do with creating the image deep inside my iOS simulator directory structure
ie-/Users/joselitope/Library/Developer/CoreSimulator/Devices/F2AE8082-E670-498B-B2C6-9A83BE1855A4/data/Containers/Data/Application/7B01A347-69AE-4A1F-8567-7FCC256013F5/tmp/comp_image_cropper_2CC9EEFB-A126-4811-BD80-485B4C41F3A2-18523-00001C049E5AAE85.jpg
but again, the file is visible using Finder so this may not be the reason.
Maybe I have to set certain permissions when creating the file in iOS or perhaps settings applicable to iOS in my pubspec.yaml?
All help is greatly appreciated.
My environment is as follows:
Catelina 10.15.7,
Flutter 1.22.5 channel stable,
XCode 12.3,
Simulator: iPhone 12 Pro Max - 14.3,
Someone posted a suggestion that prompted me to look into this problem again. (That someone has since removed his suggestion so I am unable to thank him.)
Anyways, when I tried to reproduce the problem it wasnt happening anymore even in the exact use case it was happening previously.
So the question remains is why and the only thing I ruled out that it wasnt a race condition as this code has been running on Android for quite some time on various devices.
This is what I could come up with:
Knowing the filepath I was writing to, I realized that I was writing to the app's /tmp directory which iOS periodically empties out. I am thinking that I shouldn't be putting stuff there. Instead, I've been writing to the app's documents directory and it hasnt happened since.
The initial /tmp directory was chosen for me by a package I was using and since it was so long and Im new to iOS, I didn't really look into it all that much, caring only that the file was there, which it was.
Anyways, keeping my fingers crossed that the fix sticks.
Is there a way to write in my local (not simulator) filesystem from an ios app developed with xcode, when I am running the app with Xcode's simulator ?
Reason: I have an ios application and I would like to have some content that the user could fetch as JSON data from my server. However, I would also like this JSON data to be generated from my (development) version, locally (so that I am sure it is exactly in the right format). I would therefore like my application to read and write in something like ~/User/myself/my_website/my_data/ rather than in the simulator's folder. Obviously this code would only be active in the development version and not in the release version (it doesn't need to be app review compatible).
Well, turns out it was trivial, and much simpler than writing on the device. Just specify a path to write to in the form of an absolute path and do [stringData writeToFile:path ...].
I'm packaging an iOS app built in Adobe AIR, and have noticed some odd behaviour relating to version numbers.
When I set the versionNumber in the app descriptor and build it, the resulting .ipa file has a different short version number.
Steps to demonstrate:
I set the app version number in my app descriptor to be 2.0.001, like so:
<versionNumber>2.0.001</versionNumber>
If I then compile the app, break open the resulting .ipa and check info.plist, I see the "Bundle versions string, short" as the correct value: 2.0.001
However, I see the Bundle Version as 2.0.99
This other value is definitely not set anywhere manually, this is a clean project for testing this out.
My question then, is: why would 2.0.001 become 2.0.99 when building? What's actually happening here?
Thanks in advance.
Set xml file property readOnly. Flash can't change readOnly xml files.
Looks like a bug at Adobe's side. Frustrating.
https://bugbase.adobe.com/index.cfm?event=bug&id=3598688
The following use case:
create a strings file (not localized) and deploy the application to your test device
localize the file (en.lproj or similar), make some changes to the new file and remove the original file
deploy the application on the device
What I noticed that very often (always?) the application will still use the old non-localized file. The reason is that apparently the file is still in somewhere the application bundle, even though it has been removed from the project. iOS's logic is that if a file of a specific type is looked up, it first checks in the root of the bundle for the non-localized version, and only if it doesn't find it does it go deeper into the localized folders. (Is it just me, or is this logic kind of backwards? I'm used to first looking for language specific file, and then falling back to some defaults, but it might be my Java background.)
Sometimes (always?) removing the app from the device completely doesn't help either. What does in this case is a CMD+SHIFT+K, which cleans the build folder, and after the app is built and deployed again, the correct file is used.
A worse problem would be if such a thing leads to an app crash, like some strange issues with Nibs or whatever - I have seen those as well...
The question is: what would happen if the first version of my app in the apple store had the non-localized file, and the second version localized it? When the user upgrades the app, would they get the same behavior as me during development (i.e. outdated, non-localized file used)?
I can't imagine because I think this would be a cause of a lot of grieving and bug requests, but I can't tell for sure as I haven't yet published any iOS app.
If the behavior is correct when upgrading from the store, why is it? What is so different? Are the files stored locally on my computer somewhere and used when I deploy?
Can anybody share their experiences?
I'm using CFBundleCopyResourceURL to get the path of a shader file in iOS. It returns NULL when run on the device, but works fine on the simulator. What's worse is that this works on another app setup exactly the same way to copy resources. Here are the answers to potential questions that will come my way..
The file is in a folder (shaders/shader.vsh), the folder is in my project as a reference (blue color folder in the workspace under the project). The copy bundle resources build phase has an entry for the folder (shaders)
The first parameter being passed in (bundle) is a valid main bundle which I get by calling CFBundleGetMainBundle(). I confirmed in the debugger that it is valid
I've looked at the package contents for the app image and found the files there. I also looked at the copy commands for those files in the build log and they seem fine.
So clearly, the files are getting copied into the bundle, but for some reason the function fails only on the device in one particular case.
Am I overlooking something else?
The problem turned to be case sensitivity. OSX is case insensitive and iOS is not.
Thanks to Ian Henry for mentioning it.