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
Related
To create a development environment Staging environment, I want to distribute the same version with different environment variables. ( I am using the same bundle without dividing it. )
For Android, I could deploy the same version, but for iOS, the second deployment overwrites the app on first deployment.
https://firebase.google.com/docs/reference/app-distribution/rest/v1/UploadReleaseResult
Android always had "RELEASE_CREATED" results, but iOS had "RELEASE_CREATED" results, and iOS had "RELEASE_UPDATED" results.
I confirmed that it can be distributed in the same version. But I don't know when the existing app will be overwritten.
How can I distribute the same version on iOS?
I received an answer about the reason for creating a new release.
This is a great question and one we get regularly. There are some subtle differences between iOS and Android in what is considered a new release. For Android the logic is pretty simple but for iOS it's more complicated.
If your goal is to have a new release created each time for iOS the easiest way to do it is to make sure you're also changing the version or build number.
If you really want to hold onto the same version or build number, here's how we determine whether or not to create a new release for you:
Android: If the CRC32 checksums in the APK (or AAB) don't change, we don't create a new release. If any single bit (of the uncompressed binary) is different, then a new release is created - even if versions and build numbers are identical.
iOS: We only use the UUIDs for the executable(s) (a.k.a. CFBundleExecutable) inside the IPAs to determine something we call the "instance identifier". If two uploads have the same "instance identifier", version, and build number, then no new release is created and the newly uploaded binary replaces the existing binary
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.
I keep receiving the following message from Apple when submitting my app for approval:
"iPhone 5 Optimization Requirement - Your binary is not optimized for iPhone 5. New iPhone apps and app updates submitted targeting iOS 6 and above must support the 4-inch display on iPhone 5 and must include a launch image with the -568h size modifier immediately following the portion of the launch image's filename. Launch images must be PNG files and located at the top-level of your bundle, or provided within each .lproj folder if you localize your launch images."
I'm using AIR SDK 3.9 (and I checked to make sure by tracing NativeApplication.nativeApplication.runtimeVersion).
I have a Default-568h#2x.png image in the src folder, and I checked the Project/Properties/ActionScript Build Settings/Package content (I'm using Flash Builder 4.6). It is definitely checked off to be included in the build. In "Export Release Build", I don't see it in the Package Contents there, but I don't see any of the other Default png's either, so I don't think that's the problem.
Does anyone know what I'm doing wrong?
Be sure that the launch images also located in the folder "bin-release-temp"... I have to put them manually into that folder...
The launch images cannot be referenced anywhere in the project. You cannot embed them. You cannot use them. If you do, they are not packaged as launch images, but as images used at runtime. I was having the same problem when I was referencing the images as a SplashScreenImage source. It's an unfortunate way for it to be handled, basically requiring you to include the same image twice, but it is what it is.
This link might help. It describes what and where to keep default images in air application for iPhone deployment.
http://rohitdhore1612.wordpress.com/2013/05/22/air-invalid-binary-iphone-5-optimization-requirement-your-binary-is-not-optimized-for-iphone-5/
I have trouble uploading my application to app store. When I try to archive my project for validation i get an error:
warning: iPhone/iPod Touch: BMELogo.png: icon dimensions (0 x 0) don't
meet the size requirements. The icon file must be 57x57 pixels, in
.png format (-19014) Unable to validate your application. - (null)
I have checked and re-checked my icon for both size and type. My icon is 57x57 and a PNG.
Do any of you know what to do?
in advance thanks :)
This is a weird error, but it could be similar to what happens when apps on the phone don't match what you see in the simulator. Here's a few things to try:
As Damo mentioned, this is most likely a capitalization issue. Make sure that the filename as specified in the plist matches the case of what's on disk. Devices (and the app store) are case-sensitive, but your Mac is not. If it works in the simulator but not on device, you probably have a capitalization problem.
You might need to Clean (from the Build menu) the project and rebuild. Sometimes XCode just gets confused, especially if you've been moving or renaming images. Quitting & restarting XCode might help, too.
Nuke the site from orbit -- manually delete all of the project's output files. Sometimes XCode keeps old versions of image files around packaged somewhere hidden that cleaning doesn't get rid of.
Start over from scratch. Choose a different name, one where you're sure there's no legacy object file lingering about.
Also, you might want to make sure that you are using the latest version of the Application Loader, you can download the latest by logging into iTunes Connect and clicking on Manage Your Applications, the download is at the bottom of the page.
After you download the installer, close down Xcode, then run the Application Loader installer, then relaunch Xcode, load your project, do a clean on the project, and then archive and try the validation.
I had this error too. You need to reinstall Application Loader which you can get from here https://itunesconnect.apple.com/apploader/ApplicationLoader_2.5.1.dmg
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.