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.
Related
Is it possible to maintain 2 application versions of the same application at the same time?
When a device gets too old and won't receive any updates from apple, you will stay stuck on the last version supported by your device. When downloading apps from the app store that require a higher version of iOS, it will automatically download the last compatible version from the app store. this is default behavior as stated: https://apple.stackexchange.com/questions/160089/how-does-ios-appstore-handle-multiple-version-targeting-different-version-of-ios/336985#336985
While we will mostly update our latest version, can we still update the 'legacy' versions of the app for older devices? can we still add features to the old versions (eg iOS <11) while adding the same features in our new app?
You can maintain two apps simply by giving them two different bundle ids.
But you probably cannot update the "old" app without recompiling it against the current iOS or prevent a modern user from seeing and downloading the "old" app.
To give an example, if your old app was 32 bit only, a 64 bit user cannot download it. But if you update it, you have to make it 64 bit.
I'm developing application for in-house distribution (so there can't be rejection from Apple).
As I'll distribute my app using Enterprise distribution, I'm missing one of key features of AppStore - Auto/Manual updates. (I know, that I can show popup users to update application)
Also I know, that application can download dynamic framework with code, and also can download bundle with resources.
So my question: How can I download storyboard (compiled to nib) from remote host, and load it into project?
Or is there anyway to make something like Sparkle.framework on OSX, which will update all the bundle of my app?
You can't update it silently and automatically but you can ditribuite with TestFlight or similar services. Crashlytics present an alert to update if a new version is available (and then use itms-services) .
You can even use itms-services yourself and build your own distribution system if you like.
Take a look at Artisan. They allow you to build portions of your app on their web interface and dynamically swap out views and workflow. It is generally used for A/B testing but could be used for your purposes too. This way you could change significant elements of your app without needing people to update anything. You can even setup different views for different groups of people, and again, all after application launch.
It is also free for <10,000 users, which I am assuming would not be an issue for an enterprise application.
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.
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.
Hopefully a easy(-ish) one, but I'm just wondering if it's possible to update an ad-hoc over-the-air installed iOS app (deployed using the standard $99 developer license), hence ensuring that any data stored within the app's document sandbox is still available.
Additionally if iOS 4.x file protection is used (i.e.: the NSFileProtectionComplete encrypt attribute is set on the files, etc.) will an updated app still be able to read the files?
Whilst there are some existing questions that touch on this (such as Updating enterprise iOS apps while retaining some files of the current app bundle), these don't answer this specific query and (potentially) pre-date the newer style of ad-hoc distribution.
You can definitely update an ad hoc over-the-air-installed iOS app and retain the current app data -- it appears to work identically to normal update installation.
Because it works the same way as a normal update, file protection should work the same as well, though I don't have first-hand experience.