My app ships with a folder of assets and JSON in the bundle. On first install, it takes the assets and JSON, maps it to core data and deletes the folder upon completion.
This appears to be working as expected, looking at the app bundle in the Finder via iOS simulator, I see the folder deleting and the application's footprint decreasing in size.
However, when running this on the device, the usage in settings doesn't decrease after the folder is deleted. Does anyone know why this would happen?
Thank you for your time.
The simulator is a Mac OS app. App bundles are read/write on Mac OS, so it works.
However, the app bundle on iOS is read-only. Your call to removeItemAtPath will fail on an actual iOS device.
There are various gotchas with the simulator. This is one. Another filesystem gotcha is that on most Macs, filenames ignore case. (I say "most macs" because you can configure the Mac filesystem different ways, some of which are case sensitive and some are not. The default filesystem for Mac OS volumes is not case sensitive.) However on iOS filenames are always case-sensitive. So if you write code that names a file but mismatches the case, it will work on the sim (on most Macs) but fail on a device.
There are other cases where the simulator actually uses Mac OS versions of OS frameworks to implement different APIs, and there are subtle and not-so-subtle differences in the behavior. It used to be that you could write code using NSURLDownload (a Mac OS only class) and it would compile and run on the sim, but you'd get an undefined symbol error when compiling for an actual iOS device. I don't know if this is still true.
The lesson here is to test on actual target devices, early and often.
EDIT:
Another point: Modifying your app bundle is very bad practice even on Mac OS where it works.
You cannot should not modify the app bundle in any way.
A better approach would be to supply a "seed" coredata database to copy into the Documents folder, if it doesn't currently exist.
Related
I am building an app called 'ToyBox.
When I build for iOS, I get a ToyBox.app directory which contains a ToyBox executable and the other typical iOS-related files (Info.plist, pkg.info, etc.), in addition to my app icons, assets and source code directories.
However the directory also contains another ToyBox.app sub-directory, which itself contains a ToyBox executable and iOS-related files and my assets directory.
It looks like Corona is recursively compiling my app. This happens whether I build for device or the Xcode iOS simulator. There is no problem running the resulting executable on my device (iPad4) or simulating it in Xcode but when I tried to submit my app to the App Store it was rejected with the following error:
"Invalid Bundle Structure - The binary file
'ToyBox.app/ToyBox.app/ToyBox' is not permitted. Your app may contain
only one executable file."
The error is valid - there are two executables!
(At the risk of confusing the issue, I have another, seemingly related, issue: if I build my app (either for device or Xcode simulator) then later build the app with a different name, in the same directory, the second build will include the first build and the build process will take a very long time to complete. If I was to build the app again with a third name, both previous app builds wold be included and the build would take a very (very) long time).
I can probably work around the issue by deleting the extra files, but this seems like a hack and I'd like to know what's going on.
I am using Corona Version 2013.1087 (2013.4.17).
Make sure you are not saving your Built app to the folder with your source code. You cannot put the output from building an app into the same folder with your source or you will get this error.
I am trying to run an app that someone developed and wanted me to test. The app was working fine for a long time by me placing the folder with long string of number and letters (e.g. 75E3C879-F608-45C6-A8AD-253A37FF92B8) into ~/Library/Application Support/iPhone Simulator/5.0/Applications. The simulator stopped working when I was trying to copy some new files into the same folder name without deleting the previous folder so OS X automatically appended "-1" to the end of the folder name (e.g. 75E3C879-F608-45C6-A8AD-253A37FF92B8 & 75E3C879-F608-45C6-A8AD-253A37FF92B8-1). When I launched the simulator with both those folders in ~/Library/Application Support/iPhone Simulator/5.0/Applications the simulator starts up and I see the app but when I click on it the screen flashes and then it does nothing. I have a feeling that because I had two folders with the same app it is causing some kind of error.
I am running xcode 4.2.1 on lion and have actually uninstalled and reinstalled xcode several times hoping it would clear out anything cached but have no luck so far. I don't have the actual source code so I can't create a new build myself. I've looked into all the different files that can possibly contain any reference to the app (e.g. ~/Library/Preferences/com.apple.iphonesimulator.plist, ~/Library/Caches/comapple.iphonesimulator, ~/Library/Application Support/iPhone Simulator, ~/Library/Save Application State/com.apple.iphonesimulaotr.savedState) and manually deleted them and still no luck.
I created a new user in OS X and ran the the app in the simulator without any issues so I can rule out that the build is bad. I really believe that the issue is some cache or preference tied to my user. Thanks for any help in advance.
What you are doing is a security violation, you are trying to modify the sandbox of an application from outside the application. Even if you get it to work, it should be considered a bug, because this kind of behavior doesn't make sense to allow. Can you imagine the fun time black hats would have modifying the sandbox files of an existing app to include malicious code, or modify databases? Only the app itself is allowed to modify those files.
I have an iPad application that during beta testing may need a small code update here and there, but has a large number of graphics assets (300MB+).
Is there a way of creating a partial .ipa file that just has the changes instead of re-installing the whole application along with graphics files each time?
Short answer: NO!
Explanation:
Apple gives you no means to do so !!!
The .ipa is just a .zip file. So it seems on the first look, that you can do it.
But there are 2 problems
You need direct access to the iOs Devices. You normally don't have it for your Beta-Tester.
You will need to sign your code again. This you can only do on your local machine, because you need your private key for the task
No, what you are thinking of would be considered a "patch". Apple forces you to update the entire app bundle. Take the Tomtom app for example. The app is right around 1.5GB's so for small minor changes they would need to reupload the entire 1.5GB bundle.
For the App Store builds, things have changed since iOS6 and iOS 7.1:
Starting with iOS 6, the app store will automatically produce an update package for all new versions of apps submitted to the store. When generating the update package, the app store compares one or more prior versions of your app to the new version and creates an optimized package for each that contains only the content that has changed between versions of your app, excluding any content that did not change. This comparison looks at everything in the application bundle, including the application executable, nibs, localizations, image files, video files, audio files, text files, and files containing data in a custom format.
For devices running iOS 6.x and iOS 7.0, the update package will include any file, in its entirety, that has changed in the new version of the app. For example, if you have a 10 MB file in your app and only change 1 KB of content within that file in the new version of the app, the update package for that new version will contain the full 10 MB file.
For devices running iOS 7.1 and later, the update package may include only the differences between the old and new versions of a changed file instead of the full file. This may significantly reduce the size of the update package in the case where only a small part of a large file changes, but will increase the update's installation time on the device. For this reason, the two tips above are still important even for updates on iOS 7.1 and later. Minimizing changed content and localizing it to many smaller files instead of one larger monolithic file will reduce the download size in all cases and will speed up installation on devices running iOS 7.1 and later.
Source:
https://developer.apple.com/library/archive/qa/qa1779/_index.html
I'm in version 2.3 of an app I've had in the App Store for about a year and a half. Suddenly, I submit an update to the app store with a few small changes, and now when loaded from the app store, some images won't load on all devices. It is a consistent set of images on a scrollview- it all appears black instead, but there are other pages with fewer images that consistently still work and are implemented exactly the same. No memory warnings. No SDK/XCode/OS X upgrades since last updating the app.
There are a few messages logged to the console, and those print correctly and don't indicate any problems. No errors are logged.
I'm completely at a loss for how to debug this. I'm already getting angry emails about it. I don't have time to keep resubmitting and waiting a week for it to be approved. Any suggestions?
Check the case of your image names.
Do a full rebuild of your app (ie Build->Clean).
Do a fuller rebuild - delete the "build" and simulator folders
Test on several real devices, of different generations and OS versions.
Build an Ad Hoc distribution and test that.
Generally, image problems are caused by the OS not finding the image in the app's bundle.
This can be because the device is case-sensitive whereas the simulator is not, so something that works for the simulator might not work on devices.
Also the IDE can be a bit flaky (hence the full rebuild). For some reason, I've seen resources compiled into the app never get removed, even if I clean the build. The only way to fix this is to delete the build folders, and/or the simulator folders. Simulator folders are at ~/Library/Application Support/iPhone Simulator/4.3.2/Applications/ (or whatever your build version was). You can trash the build folders without worry, but don't delete too much in Application Support or else you might need to re-install XCode; just find the GUID (ABCDEF01-2345-6789-ABCD-EF0123456789) that matches your app.
An Ad Hoc build, especially if you base it off of your Release configuration, will probably be the closest thing to a real build that you can get. There are tricks to using the command-line codesign utility to take a release build and change its signature so that you can run it as an ad-hoc but that's definitely not low-hanging fruit.
Make sure that all your image files are in your test app bundle and submitted app bundle, and not in subdirectories in your test app bundle, and that the upper/lower case and spelling of all file names is identical within all usages inside and outside the app.
We're iOS (and other mobile platform) developers and our sales folks routinely need to provide demos of our apps for clients. What we're trying to do is automate a process so sales people can go to a self-serve website and feed the app into their simulator.
Using xcodebuild we can kick off the build process and then present it as a secure download link (via our intranet) but all that lets them do is install it to their iOS device. This is OK except not everyone on the road has an iOS device (or some have old iPod touches, and that's super slow). So, I was thinking that there's gotta be a way to get it installed in their simulator.
I see that others have hacked it in there by zipping up a simulator directory and placing it on another:
http://discussions.apple.com/thread.jspa?messageID=7680994
Set target to simulator, release.
deploy. stop iphone simulator. zip
your app from ~/Library/Application
Support/iPhone
Simulator/User/Applications/ send it
to someone else, and let that person
know to unzip it in that folder, than
start iphone simulator - and you're
done.
I guess we can do this, but it doesn't seem deterministic (or at least, a lot harder to script). I'd prefer to work with the .app but if the only way to do it is with this hacky copy and paste operation, that'll be what we have to do.
Any thoughts?
This could work: https://github.com/landonf/simlaunch/
I have not tried it yet by myself, but from video looks like the application converts .app compiled for simulator to a launcher, which can be used to run the app in simulator without installing it through xcode.
It probably uses the same kind of approach for simulating the app without installing it first that is described here: How to install iPhone application in iPhone Simulator
I know this isn't a direct answer to your question, but have you thought about having a server (eg a Mac mini) that has all the installed software on it? Then they could just use some form of screen sharing to run the app remotely.
I've used the simulator build mechanism above with a number of clients and once they figure out the right folder to drop the actual folder into, it's gone very well.
It's a little bit of a hack as you say but in some cases it also beats having to deal with ad hoc provisioning etc when it's less important to have it on an actual device itself.
I haven't tried it yet but I've heard pretty good things about Test Flight (http://testflightapp.com/) also as a way to distribute demos/betas so that might be worth a look as well.
I just developed a pair of scripts to (a) extract an app from a iOS simulator, and (b) install it on another iOS simulator. https://github.com/christopher-prince/SimAppScripts
Locate the .app bundle in your built products directory, typically under Debug-iphonesimulator or Release-iphonesimulator. Drag and drop that bundle onto the Simulator window and it will be installed (you may need to swipe on the home screen to show the icon).
You can also script this from the command line using xcrun simctl install. The xcrun simctl launch command can also start the application.
Most build systems can be automated (or you can use a post-build script from within Xcode, ordered as the last step) to create a ZIP of the app bundle and put it somewhere for download.
(If having the Archive workflow support creating Simulator IPAs would be useful for you please file an enhancement request at https://bugreport.apple.com)
check out waxsim:
https://github.com/square/WaxSim
http://cocoamanifest.net/articles/2011/12/running-your-ios-app-in-the-simulator-from-the-command-line.html
If you build it for i386 and distribute the .app, I believe this will work.