I managed to squeeze down texture/image data for my game to 20mb to allow 3G downloads. I would like to stay below 20mb, even if my app gets updated (additional texture data). In order to allow future updates, the app copies all textures/images from the main bundle to the Documents directory (which is not altered when an app is updated). When the app starts, it checks if the required textures exist in the Documents folder. If they dont exist, textures are copied from the main-bundle to the document directory.
My updates should only contain new texture data (which is again copied to the document folder) and a modified binary. Is this possible? How does apple update ios apps? My approach only works, if updates are applied sequentially when a user decides to update an app:
1) original version is installed
2) update available -> install
3) update available -> install
...
The described approach will not work, when apple only provides the "latest" version (because all previous updates are missing).
I hope somebody can shed some light on the update process.
thanks
In your own words:
The described approach will not work, when apple only provides the
"latest" version (because all previous updates are missing).
Once you submit a new version and is approved by Apple, your previous binary will no longer be available to the consumer, your latest binary will be the only version of the application available in the AppStore.
This means that new users will only download the latest version and existing users can skip versions when updating. Versions must be standalone and not "patches" for previous versions.
Related
I want to submit an update for my iOS app, but this seems to require submitting a new version which entails re-entering all information, screenshots, videos, etc.
I can't find anything that explicitly says one can submit solely a new build for an existing version that has already been approved. Is this possible?
If not, is there a way to copy over all of the previous version's information, screenshots, videos, etc. within iTunesConnect?
EDIT:
Specifically, the problem is that screen-shots and app-previews from the previous approved version do not show up by default.
For anyone googling here:
The problem is this:
It annoyingly defaults to (say) 6.5 !!!
(Whatever is current as you are reading this.)
And it's likely you have no images you likely have no images for that size!
Simply click on the other sizes to see your existing images!
That's all it is.
2019 note ..
As #phihag mentions below, they're always changing "just which one is actually required," but in all events you can click around away from the default to see what's happening. You may then come to realize that Apple now requires image sizes that are NOT in your previous release, and so you now need to generate a new set of images.
There is no need to upload screenshots, videos and other information again and again when you are publishing a new version. Unless you have a new functionality which you want to be presented in the screenshots or you have to support a new apple device. For example your previous version didn’t support iPhone X, then when you create a new version, there won’t be any screenshot for iPhone X. So you need to upload screenshots only for that specific device.
So, just create the New version and upload the new build and add - What's new in this version. You are then good to go.
As to your question on whether it is possible to upload a new build to existing live version. Answer to that is - NO. Once an app is live, you always have to create a new version on iTunesConnect and upload build configured with that version number.
As an example, here are two images :
1. Already existing app on iTunesConnect (live version)
2. New version created. Screenshots already there by default.
I have an application that is currently in the App Store.
It has approximately 500mb of data that it needs in order to run.
I was fighting and fighting various methods to install this data after the app was downloaded, including AFNetworking and WhiteRaccoon, to no avail... the deadline was coming fast, so I decided to just ahem bundle the content into the App Bundle, and worry about it later. This meant the size of the app dictated that people downloaded it while on WiFi, but ... whatever.
Now, I have discovered NSURLSession, much to my delight, and it does everything that I need that I couldn't make the others do (see my answer to this question).
So... I am ready to push a new update to the App Store, and my Archive size has been reduced from 491.2mb to 32.2mb (!!?woohoo?!!).
I am curious how Apple manages this. I have read this document that mentions techniques that they use to keep the app bundle size down by detecting what hasn't changed, but it doesn't explicitly mention anything about the scenario that I am facing.
Now, if 460mb or so of obsolete bundle/code is going to be stored in the user's device, I'd like to be able to recommend to them that they delete the app entirely and reinstall... but I am curious if I/they need to do this, or does anyone know how Apple will handle this scenario ?
Thanks.
That document you reference, Technical Q&A QA1779: Reducing Download Size for iOS App Updates, covers what Apple does to optimize the size of the app update. But the net effect is the same as if the app bundle on the user's device was entirely replaced. As that document says:
In addition to new content, the update package contains instructions on how to transform the prior version of the app into the new version of the app. New files will be added, modified files will be replaced with their updated counterpart, and deleted files will be removed as part of this transformation. As far as the developer and user are concerned, this process is entirely transparent and the resulting updated app will be indistinguishable from a full download of the corresponding updated version of their app.
So, no, you don't have to tell users to delete the old app unless there's anything in persistent storage (Documents, NSUserDefaults, etc.), that need to be reset. And you should probably handle that programmatically, anyway.
I released an update for my App and it was approved. It was approve despite the fact that it included a serious localization bug where most users are getting the wrong language. Is there any way to quickly revert back to the previous version, suspend current downloads of the current version, or anything else that might help aid this issue?
I did read the following thread from a couple years ago:
Can I revert to my previous version app in iTunes Connect?
I was hoping maybe there is a more painless solution to this now.
Btw, I did thoroughly test the version before it was added as a new version. So, I'm still not entirely sure what's wrong or how to fix it.
It is not possible to revert the app version. You can upload the previous version as new version again to fix this.
One thing you can do is : "Expediting an App Review"
Please check the following link.
https://developer.apple.com/appstore/contact/?topic=expedite
Thanks
Here's a snippet from iTunes Connect Help page :
Question: The new version of my app on the App Store has a bug. Can I use a previous version to replace it?
No. You cannot revert to a previous version on the App Store. You must submit a new version.
Source : iTunes Connect FAQ
Obviously the alternative would be to submit a new build but ask for expedited app review.
But that means that either your app is event-related or you have a critical bug that you need fixed as soon as possible.
I believe that you can prepare for problems by creating a fallback version with a higher version number and submitting it for approval with manual publishing. That should cause it to be quiescent in your store until you choose to fall back, and you publish it.
I am not certain whether you can then submit improved versions with a lower version number than your fallback version.
I had to do this recently. I was able to adjust a previous version archive. I started by copying the archive and opening the copy, then editing the info.plist files, adjusting/incrementing both the version and build numbers at both the archive and app package levels. Then uploaded to iTunes, which recognized it as a new version.
Preface: I agree with the other posts here that you can't perform a rollback through the iTunes Connect itself. Even if you could, you'd suffer the lag time it takes for users to update to the rolled-back-version. But that doesn't mean we can't still rollback apps.
Retroactively, you cannot rollback an app. Proactively, however, you can instrument your app to enable future rollbacks after a build has been released and installed.
High-level steps:
Build each version of your application as a framework
For each release build, include both the current and old framework versions
On app boot, decided which framework to load and execute (include sane defaults)
When you want to rollback, update the cached values across all user devices and wait for the next app open.
This strategy uses similar mechanics to feature flags which are commonly used to enable/disable features without re-releasing. However, in this case, you're "feature-flagging" your entire app version.
Is feature flagging between embedded libraries against App Store Guidelines?
No. Embedding two versions of your app into one release is not against App Store review guidelines:
4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g.
HTML5-based games, bots, etc.), as long as code distribution isn’t the
main purpose of the app, the code is not offered in a store or
store-like interface, and provided that the software (1) is free or
purchased using in-app purchase; (2) only uses capabilities available
in a standard WebKit view (e.g. it must open and run natively in
Safari without modifications or additional software); your app must
use WebKit and JavaScript Core to run third-party software and should
not attempt to extend or expose native platform APIs to third-party
software;
Similar to feature flags, all code that you plan to run is included in the binary that you submit for review. What's more, as long as you are rolling back to releases that Apple already reviewed and approved, you're not breaking the spirit of the guidelines.
Does this hurt performance?
I've profiled this approach against many of the popular and heavy open-source iOS apps including Wikipedia, Signal, Firefox, etc. You can be smart about deduping assets and shared libraries, resulting in a sandwiched-app-bundle size of about 1.2x the original size (really just depending on how much code you changed). You also incur about a 50ms startup cost when choosing which version of the app to boot.
IMO, both time and size increases are worthwhile in return for the ability to selectively rollback users experiencing issues while you take time implementing a fix.
Do real apps do this?
Major apps feature-flag between dylibs all the time when launching new features and optimizing performance. I have also heard of major tech companies using this app-level pattern for their largest releases. I have a personal app in the App Store using this pattern, and I have helped other developers do the same.
How can someone do this for their app
If you are comfortable going deep on the Xcode build system, you can follow the steps outlined above and with some fiddling, start feature flagging your app version on boot. Note that you'll also need some form of caching and a server endpoint to update the on-device flag.
The implementation described above is also exactly how screenplay.dev implements iOS rollbacks. The tool:
Adds two build targets to your Xcode project, one for building the framework version, and one for bundling the final release build.
Serves as a repository for your old app build versions.
Provides a web UI for toggling live versions.
When submitting an update to an app to the app store (via iTunes Connect?), is the update necessarily a whole binary? Can an update come in the form of a patch? If a second version of an app shares a lot of assets and logic from the previous version, does all that logic/resources get reinstalled wholly regardless?
There are no patches. It's installed as an entire read-only bundle. The old bundle is replaced with the new bundle.
Application data is retained (ie. documents folder, NSUserDefaults).
As everyone said before me Apple does not supply a way to hot-patch native apps, moreover it has a clear restriction - "No remote code injection".
The only thing I can add is that hybrid apps which use a javascript platform allow you to remotely replace the JS file, so you can actually change functionality remotely.(without having to release a new version) other solutions I have seen are in the gray area and allow you to run Lua Script remotely to change app functionality.
We # Rollout.io have a different approach, we allow you to hot-patch production apps without code injection on native applications, you can read more on how the tech works here
Rollout is meant to help mobile developers solve production quality issues, hot-patching production apps, debugging production env, adding/removing analytics, etc.
Disclosure: I'm from the Rollout.io team.
iOS 6 now supports delta app updates. This is awesome, and makes Real Racing 3 (a 1.1GB app) update in about 30 seconds instead of 20 minutes!
https://developer.apple.com/library/ios/#qa/qa1779/_index.html
Q: How can I reduce the downloaded size of my app update for users
that already have the previous version installed?
A: Starting with iOS 6, the app store will automatically produce an
update package for all new versions of apps submitted to the store.
This package is optimized for updating an app from one version to
another, and contains files that have changed between the prior
version of an app and the new version of the app, excluding files that
have not changed.
When used optimally, an update package is significantly smaller to
download than the full package of the app and the update will install
more quickly. Also, in many cases, this mechanism allows updates to
large apps to be downloadable over cellular networks where app
downloads are subject to a size limit.
In addition to new content, the update package contains instructions
on how to transform the prior version of the app into the new version
of the app. New files will be added, modified files will be replaced
with their updated counterpart, and deleted files will be removed as
part of this transformation. As far as the developer and user are
concerned, this process is entirely transparent and the resulting
updated app will be indistinguishable from a full download of the
corresponding updated version of their app.
Further instructions for developers available at the link above.
I have an app on AppStore that I would like to improve with StoryBoard. I was recomended to build a new app from scratch instead of trying to add storyboard to an old app. So I have done that and now I would like to upload it to the AppStore and replace the old one.
I understand that the bundle identifier and app name must be the same. Do I have to make sure any other stuff is the same?
Yes, you can do this no problem.
Just make sure to use the same App bundle identifier i.e. com.companyname.appname as in your original app.
Then use the same distribution license that you would normally use.
You have to release the new app as an update to the old app but apart from that you can change anything else.
You also have to make the new version number greater than the current apps version number.
To the users it will look like a normal update but in the background you will have essentially replaced the entire app.
You could consider this as an update of you app.
Bundle version should be higher then before (for example 1.1 or 2.0 if the previous one is 1.0) - this usually depends on how big the difference will seem to the users.
And also: if you are saving anything to documents folder make sure that the new version is compatible with the old data.
New version should be able to run on device:
if there was (any) previous version installed
if there was no previous installation of your app